Due to advancements in processing technology, complex integrated circuits (ICs) can be designed using various levels of abstraction. Using a hardware description language (HDL), circuits can be designed at the gate level, the register transfer level (RTL), and higher logical levels. When designing using an HDL, the design is often structured in an object-oriented manner. The designer describes the behavior of a system in terms of signals that are generated and propagated through combinatorial modules from one set of registers to another set of registers. HDLs provide a rich set of constructs to describe the functionality of each module. Modules may be combined and augmented to form even higher-level modules.
System-level integration relies on reuse of previously created designs, from either within an enterprise or from a commercial provider. Libraries of pre-developed blocks of logic have been developed that can be included in an FPGA design. Such library modules include, for example, adders, multipliers, filters, and other arithmetic and DSP functions from which system designs can be readily constructed. The engineering community sometimes refers to these previously created designs as “design modules”, “cores”, or “IP” (intellectual property). The use of pre-developed logic cores permits faster design cycles by eliminating the redesign of circuits. Thus, using cores from a library may reduce design costs.
During the process of developing a circuit design, the behavior of the design is simulated based on a specification of the circuit design. Simulating the design helps to verify correct behavior prior to physical implementation of the circuit. Wasted manufacturing costs due to faulty design may thereby be avoided. Numerous tools are available for simulating circuit designs including, for example, high-level modeling systems (HLMS) and hardware description language (HDL) simulators.
In order to verify how a circuit design will behave when realized in hardware an HLMS simulation model, which is both bit-accurate and cycle-accurate, is used. Although it is possible for a block in an HLMS to have a model that is both bit- and cycle-accurate, it is often the case that a separate bit-accurate simulation model is necessary, because the implementation involves significant structural code that results in unacceptably slow simulation within the HLMS.
For example, an HLMS simulating digital signal processing (DSP) or digital communications applications could include blocks for finite impulse (FIR) and infinite impulse response (IIR) digital filters, fast Fourier transforms (FFTs), or error-correcting codecs. For high-level functions, providing a separate bit-accurate simulation model in a high-level language such as C++ may provide a faster simulation model.
To ameliorate the simulation requirements of design verification, many vendors provide timed behavioral models for most logic cores to improve simulation speeds of the design during verification and test aspects of design cycles. Internally, such models are used to ensure quality. However, creating timed behavioral models is time consuming and potentially difficult in cases of cores such as FFTs. With these types of cores, the computations involved slow down the simulation of the HDL behavioral model, which necessitates the use of a C/C++ model for verification. In other circumstances, C/C++ models of various DSP functions are readily available. However, the same cannot be said for HDL models of DSP-specific functionality. The C/C++ models, however, cannot be used alongside implementations of the core in a cycle-accurate simulation environment, because of the absence of timing information.
Current methods to integrate separate bit-accurate and cycle-accurate behavior models involve manual integration of a C-based bit-accurate model and an HDL-based cycle-accurate model using C/C++ for to implement an interface between the models to provide a cycle-accurate behavioral model. The C-based data-path model and HDL-based control-path model are integrated in a high-level modeling tool such as System Generator for DSP (“SysGen”). This manual process is error-prone and contributes to a sustained maintenance burden on developers. The control-path and data-path interfaces are not standardized to allow the use of this approach to other high-level cores without laborious manual intervention. Because of the manner in which the interface is created, simulation tools outside of the simulation tool used for integration cannot benefit from this technology.
The present invention may address one or more of the above issues.